Expedited User Authentication

ABSTRACT

A system for granting access to an account at an access device includes a computer server having a hardware processor and a memory storing a software code. The hardware processor executes the software code to receive a login request from the access device through a first communications socket, open a second communications socket between the access device and the computer server, transmit a verification request message including a required call-to-action to a verification device through a third communications socket, and receive a verification response message verifying that the required call-to-action has been completed at the verification device. Upon receiving the verification response message, the software code sends an access token for accessing the account to the access device through the second communications socket, receives the access token from the access device, and grants the access device access to the account.

BACKGROUND

The use of multiple computing platforms to access content provided bythe same service is increasingly common. For example, a personsubscribing to a streaming media service, such as Netflix® or Hulu®) forexample, may at various times use a smartphone, tablet computer laptopcomputer, smart television., and a dedicated streaming media player toconsume content of their choice. Although such cross platformaccessibility to content confers many benefits, even basic measurestaken by streaming services to ensure user account security can make useof multiple platforms frustrating.

For instance, users often forget their passwords, which may make itdifficult and time consuming to access their account from a device thatthey are not ahead logged into their account on. Also, there may be usecases in which an account holding user wishes to log in to their accountfrom the home of a friend so that they can consume content associatedwith the account together or with a group. In some of those cases theaccount holding user may prefer not to have to disclose his/her passwordor other authentication credentials in the group setting in order tologin.

SUMMARY

There are provided systems and methods for expediting userauthentication, substantially as shown in and/or described in connectionwith at least one of the figures, and as set forth more completely inthe claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A shows a diagram of an exemplary system for expediting userauthentication, according to one implementation;

FIG. 1B shows a diagram of a system for expediting user authentication,according to another exemplary implementation;

FIG. 1C shows a diagram of a system for expediting user authentication,according to yet another exemplary implementation;

FIG. 2 is a flowchart presenting an exemplary method for use by a systemfor expediting user authentication to grant access to an account at anaccess device, according to one implementation;

FIG. 3 shows an exemplary login request received from an access device,according to one implementation;

FIG. 4 shows an exemplary delivery prompt transmitted to an accessdevice, according to one implementation;

FIG. 5 shows an exemplary verification request message transmitted by asystem expediting user authentication, according to one implementation;

FIG. 6 shows an exemplary message informing an access device of asuccessful login; and

FIG. 7 shows a diagram of a system for expediting user authentication,according to another exemplary implementation.

DETAILED DESCRIPTION

The following description contains specific information pertaining toimplementations in the present disclosure. One skilled in the art willrecognize that the present disclosure may be implemented in a mannerdifferent from that specifically discussed herein. The drawings in thepresent application and their accompanying detailed description aredirected to merely exemplary implementations. Unless noted otherwise,like or corresponding elements a figures may be indicated by like orcorresponding reference numerals. Moreover, the drawings andillustrations in the present application are generally not to scale, andare not intended to correspond to actual relative dimensions.

The present application discloses systems and methods for expeditinguser authentication that overcome the drawbacks and deficiencies in theconventional art. It is noted that, in some implementations, the presentuser authentication solution may be performed as a substantiallyautomated process by a substantially automated system. It is noted that,as used in the present application, the terms “automation,”“automated”,and “automating” refer to systems and processes that do not require theparticipation of a human user, such as a system administrator. Although,in some implementations, a human system operator or administrator mayreview the performance of the automated systems described herein, thathuman involvement is optional. Thus, the methods described in thepresent application may be performed under the control of hardwareprocessing components of the disclosed automated systems.

FIG. 1A shows a diagram of an exemplary system for expediting userauthentication, according to one implementation. As discussed below,system 100 may be implemented using a computer server accessible over alocal area network (LAN) or may be implemented as cloud-based system. Asshown in FIG. 1A, system 100 includes computing platform 102 havinghardware processor 104, and system memory 106 implemented as anon-transitory storage device. According to the present exemplaryimplementation, system memory 106 stores user database 120 includinguser account 122 and biometric profile 126 of user 140, as well assoftware code 110 for expediting authentication of user 141.

As also shown in FIG. 1A, system 100 is implemented within a useenvironment including communication network 130 providing firstcommunications socket 131, second communications socket 132, and thirdcommunications socket 133, as well as access device 143 of user 141coupled to display 144, verification device 146 of user 141 includingdisplay 148, and user 141 interacting with system 100. Also shown inFIG. 1A are login request 150, verification request message 152,verification response message 154, access token 124, biometric data 156,delivery prompt 157, and notification 158.

It is noted that although the present application refers to softwarecode 110 and user database 120 as being stored in system memory 106 forconceptual clarity, more generally, system memory 106 may take the formof any computer-readable non-transitory storage medium. The expression“computer-readable non-transitory storage medium,” as used in thepresent application, refers to any medium, excluding a carrier wave orother transitory signal that provides instructions to hardware processor104 of computing platform 102. Thus, a computer-readable non-transitorymedium may correspond to various types of media, such as volatile mediaand non-volatile media, for example. Volatile media may include dynamicmemory, such as dynamic random access memory (dynamic RAW, whilenon-volatile memory may include optical, magnetic, or electrostaticstorage devices. Common forms of computer-readable non-transitory mediainclude, for example, optical discs, RAM, programmable read-only memory(PROM), erasable PROM (EPROM), and FLASH memory.

It is further noted that although FIG. 1A depicts software code 110 anduser database 120 as being co-located in system memory 106, thatrepresentation is also provided merely as an aid to conceptual clarity.More generally, system 100 may include one or more computing platforms102, such as computer servers for example, which may be co-located, ormay form an interactively linked but distributed system, such as acloud-based system, for instance. As a result, hardware processor 104and system memory 106 may correspond to distributed processor and memoryresources within system 100. Thus, it is to be understood that userdatabase 120, as well as various features of software code 110 may bestored and/or executed using the distributed memory and/or processorresources of system 100.

In one such implementation, computing platform 102 of system 100 maycorrespond to one or more web-based computer servers, accessible over apacket-switched network such as the Internet, for example. In thatimplementation, first, second, and third communications sockets 131,132, and 133 may take the form of WebSocket protocol communicationchannels, for example. However, in other implementations, computingplatform 102 may correspond to one or more computer servers supporting awide area network (WAN), a LAN, or included in another type of limiteddistribution or private network. Accordingly, computing platform 102will hereinafter be referred to as “computer server 102.”

According to the implementation shown by FIG. 1A, user 141 may utilizeverification device 146 to interact with system 100 over communicationnetwork 130 to expedite login of access device 143 to a web-basedservice account held by user 141, i.e., user account 122. In oneimplementation, access device 143 may be an entertainment device, suchas a game console, streaming device, or other digital media player, thatuser 141 wishes to log in to in order to access content, andverification device 146 may be a smartphone, tablet computer, laptopcomputer, desktop computer, or other primary device of the user 141 foraccessing emails, text messages, and other types of accounts and variousforms of communication.

That is to say, verification device 146 may be any suitable system thatimplements data processing capabilities sufficient to provide a userinterface, support connections to communication network 130, andimplement the functionality ascribed to verification device 146 herein.In other implementations, verification device 146 may take the form of adesktop computer, a laptop computer, a game console, a smart television(smart TV), a streaming media player, or a wearable communication devicesuch as a smartwatch or augmented reality (AR) or virtual reality (VR)headset or glasses, to name a few examples.

With respect to display 144 coupled to access device 143, display 144may be communicatively coupled to but physically separate from accessdevice 143, as shown in FIG. 1A, or may be physically integrated withaccess device 143. For example, where access device 143 is implementedas a smart TV, display 144 will typically be integrated with accessdevice 143. By contrast, where access device 143 is implemented as astreaming media player, display 144 may take the form of a monitorseparate from access device 143. Analogously, display 148 may bephysically integrated with verification device 146, as shown in FIG. 1A,or may be communicatively coupled to but physically separate fromverification device 146. For example, where verification device 146 isimplemented as a smartphone, laptop computer, or tablet computer,display 148 will typically be integrated with verification device 146.By contrast, where verification device 146 is implemented as a desktopcomputer, display 148 may take the form of a monitor separate fromverification device 146 in the form of a computer tower. Displays 144and 148 may be implemented as liquid crystal displays (LCDs),light-emitting diode (LED) displays, organic light-emitting diode (BLED)displays, or any other suitable display screens that performs a physicaltransformation of signals to light,

According to the exemplary implementation shown in FIG. 1A, user 141 isthe account holder of user account 122. In addition, user 141 is theowner of access device 143 and verification device 146. Thus, the usecase depicted by FIG. 1A is one in which user 141 utilizes his/her ownverification device 146 to expedite login to his/her own user account122 using access device 143 of user 141. As a specific example, whereaccess device 143 is a streaming media player and display 144 is a TVcoupled to streaming media player 143, user 141 may utilize verificationdevice 146 in the form of a smartphone, for example, to expedite loginto user account 122 by access device 143 in order to consume movie, TV,or game content associated with user account 122 using access device 143and display 144.

By way of contrast, and referring to FIG. 1B, FIG. 1B shows a diagram ofsystem 100 for expediting user authentication, according to anotherexemplary use case. According to the exemplary use case shown in FIG.1B, user 141 is the account holder of user account 122. In addition,user 141 is the owner of verification device 146. However, in thepresent use case, user 141 is a guest of secondary user 142, who ownsaccess device 143 and display 144, and acts as a host to user 141. Thus,the use case depicted by FIG. 1B is one in which user 141 utilizeshis/her own verification device 146 to expedite login to his/her useraccount 122 by access device 143 belonging to secondary user 142. As aspecific example, there access device 143 is a streaming media playerand display 144 is a TV coupled to streaming media player 143, user 141may utilize verification device 146 in the form of a smartphone, forexample, to expedite login to his/her user account 122 by access device143 belonging to secondary user 142, in order to consume movie, TV, orgame content to which user 141 has an entitlement, together withsecondary user 142, using access device 143 and display 144 of secondaryuser 142.

By way of further contrast, and referring to FIG. 1C, FIG. 1C shows adiagram of system 100 for expediting user authentication, according toyet another exemplary use case. According to the exemplary use caseshown in FIG. 1C, user 141 is the account holder of user account 122. Inaddition, user 141 is the owner of verification device 146. However, inthe present use case, user 141 is physically remote from secondary user142, who owns access device 143 and display 144. Thus, the use casedepicted by FIG. 1C is one in which user 141 utilizes his/her ownverification device 146 to expedite login to his/her own user account122 by access device 143 belonging to secondary user 142, in order toenable secondary user 142 to access content to which user 141 holds anentitlement. As a specific example, where access device 143 is astreaming media player and display 144 is a TV coupled to streamingmedia player 143, user 141 may utilize verification device 146 in theform of a smartphone, for example, to expedite login to his/her useraccount 122 by access device 143 belonging to secondary user 142, inorder to enable secondary user 142 to consume movie, TV, or game contentto which user 141 has an entitlement, without user 141 being in thecompany of secondary user 142.

The functionality of system 100 will be further described by referenceto FIG. 2 in combination with the specific exemplary implementationshown in FIG. 1A. FIG. 2 shows flowchart 260 presenting an exemplarymethod for use by a system for expediting user authentication to grantaccess to an account at an access device, according to oneimplementation. With respect to the method outlined in FIG. 2 , it isnoted that certain details and features have been left out of flowchart260 in order not to obscure the discussion of the inventive features inthe present application.

Referring to FIG. 2 in combination with the exemplary implementationshown by FIG. 1A, flowchart 260 begins with receiving, through firstcommunications socket 131 between access device 143 and computer server102, login request 150 from access device 143 (action 261). Loginrequest 150 includes information identifying access device 143 andinformation identifying user 141 of access device 143, the informationidentifying user 141 being linked to user account 122 of user 141.

User 141 may utilize access device 143 to launch a web browser ondisplay 144 and attempt to log in to user account 122 held by user 141,such as a streaming media service account, for example. In theparticular use case depicted by FIG. 1A, user 141 may have previouslysetup an account with system 100, but may have used a communicationdevice or system other than access device 143 for previous logins, suchas verification device 146 for example. An account password typicallyrequired for login to user account 122 may not be remembered by user141, thereby creating an obstacle to login and resulting in user 141sending login request 150 to system 100, soliciting assistance incompleting the login process.

Login request 150 may be received by software code 110, executed byhardware processor 104, via communication network 130 and firstcommunications socket 131. In some implementations, login request 150may include a failed login attempt. As noted above, login request 150includes at least information identifying user 141, and informationidentifying access device 143 from which login request 150 originates,such as a device identifier of access device 143, as known in the art.In some implementations, login request 150 may also include thegeographical region in which access device 143 is located, as well asinformation linking login request 150 to user account 122. For example,login request 150 may include a username of user 141, an email addressof user 141, a mobile phone number of user 141, or biometric data 156 ofuser 141, such as a facial scan, retinal scan, fingerprint, voicesample, or the like. In one implementation, the information linkinglogin request 150 to user account 122 may be entered into a graphicaluser interface (GUI) provided by access device 143. For example, user141 may use an input device, such as a keyboard, game controller, remotecontrol, and/or voice remote to enter a username or email associatedwith his/her account, and characters for the user's username or emailmay be populated/displayed into a display field of a login screen of theGUI.

The information identifying user 141 that is included in login request150 may also identify verification device 146. For example, loginrequest 150 may include a unique address associated with verificationdevice 146, such as a phone number, or a secondary account (e.g., emailor social media account) that verification device 146 is logged into.Moreover, in some implementations, login request 150 may include a datastructure, such as a JSON object enabling display of a message to user141, or for use in updating a decision tree flow or providing any othernecessary business logic for authenticating access device 143 andexpediting login by user 141.

FIG. 3 shows exemplary login request 350 received from access device143, according to one implementation. Login request 350 corresponds ingeneral to login request 150, in FIGS. 1A, 1B, and 1C. Thus, loginrequest 150 may share any of the characteristics attributed tocorresponding login request 350 by the present disclosure, and viceversa. As shown in FIG. 3 , login request 350 includes an opportunityfor a user to login by entering a password in password field 370 andselecting login button 372. Alternatively, the user may provide otheruser information, such as by populating username field 373, email field374, or phone number field 376, for example, and follow instruction 378.For example, in one implementation, user 141 may not remember his/herpassword or may be having trouble using his/her login credentials, andaccess device 143 may prompt user 141 to provide the other userinformation as part of an alternative login process.

Flowchart 260 continues with, in response to receiving login request150, opening second communications socket 132 between access device 143and computer server 104 (action 262). As noted above, in someimplementations, second communications socket 132 may be a WebSocketprotocol communication channel. Opening of second communications socket132 between access device 143 and computer server 102 may be performedby software code 110, executed by hardware processor 104.

Flowchart 260 continues with, upon opening second communications socket132, generating verification request message 152 including acall-to-action at verification device 146 of user 141, as well as avalidation code (action 263). It is noted that the validation codeincluded in verification request message 152 may be embedded inverification request message and may not be visible to user 141.Referring to the exemplary implementation shown by FIG. 1A, hardwareprocessor 104 of system 100 may execute software code 110 to generateverification request message 152.

Flowchart 260 continues with transmitting verification request message152 including the call-to-action and the validation code to verificationdevice 146 through third communications socket 133 (action 264). Asshown in FIG. 1A, hardware processor 104 of system 100 may executesoftware code 110 to transmit verification request message 152 toverification device 146 of user 141, via communication network 130 andthird communications socket 133.

In some implementations, it may be advantageous or desirable to notifyuser 141 that verification request message 152 has been transmitted toverification device 146. In those implementations, the present methodmay include transmitting delivery prompt 157 to access device 143,wherein delivery prompt 157 informs user 141 that verification requestmessage 152 has been transmitted to verification device 146.

FIG. 4 shows exemplary delivery prompt 457. Delivery prompt 457corresponds in general to delivery prompt 157, in FIGS. 1A, 1B, and 1C,and those corresponding features may share any of the characteristicsattributed to either feature by the present disclosure. It is noted thatalthough delivery prompt 457 identifies verification request message 152as an email message, that representation is merely exemplary. As notedabove, in other implementations, verification request message 152, aswell as delivery prompt 157/457, may be a Short Message Service (SMS)text message. In implementations of the present method that includetransmittal of delivery prompt 157/457, delivery prompt 157/457 may betransmitted to access device 143 by software code 110, executed byhardware processor 104.

FIG. 5 shows exemplary verification request message 552 according to oneimplementation. Verification request message 552 corresponds in generalto verification request message 152, in FIGS. 1A, 1B, and 1C. Thus,verification request message 152 may share any of the characteristicsattributed to corresponding verification request message 552 by thepresent disclosure, and vice versa. As shown in FIG. 5 , verificationrequest message 552 includes validation code 582 and informs user 141that login request 150/350 was received, identifies access device 143,i.e., Streaming Media Player A, from which login request 150/350 wasreceived, and requests that user 141 authorize login by access device143.

Verification request message 552 may take a variety of forms. Forexample, in some implementations, verification request message 552 maybe transmitted to user 141 as an email message. However, in otherimplementations, verification request message 552 may be transmitted asan SMS text message including validation code 582 as an embedded link,for example. In either implementation, verification request message 552may enable user 141 to authorize login of access device 143 throughperformance of a call-to-action at verification device 146. For example,as shown in FIG. 5 , such a call-to-action may be executable by a singleclick authorization on verification request message 552 at click-backauthorization field 580.

Flowchart 260 continues with receiving, through third communicationssocket 133, from verification device 146 and in response to the requiredcall-to-action, verification response message 154 including verificationthat the required call-to-action has been completed at verificationdevice 146 of user 141 (action 265). In some implementations,verification response message 154 may correspond to verification requestmessage 152/552 after use of verification device 146 to perform singleclick selection of authorization field 580 by user 141. That is to say,verification response message 154 may return validation code 582included in verification request message 152/552 to system 100 forredemption in response to user 141 performing single click selection ofauthorization field 580.

However, in other implementations, the required call-to-action includedin verification request message 152/552 may be input of biometric data156 of user 141, such as a facial scan, retinal scan, fingerprint, orvoice sample of user 141, for example. In those latter implementations,verification response message 154 may include biometric data 156 as wellas validation code 582 included in verification request message 152/552.In some of those implementations, biometric data 156 may be comparedwith biometric profile 126 of user 141 in order to expediteauthentication of user 141. Verification response message 154 may bereceived by software code 110, executed by hardware processor 104, viacommunications network 130 and third communications socket 133.

It is noted that, in some implementations, validation code 582 includedin verification request, message 1521552 and returned to system 100 inverification response message 153 may be redeemable during a redemptiontime window beginning when verification request message 152/552 istransmitted to verification device 146 in action 264, such as a fifteenminute redemption time window merely as an example. In some of thoseimplementations, hardware processor 104 may further execute softwarecode 110 to send access token 124 through second communications socket132 to access device 143 if validation code 582 is received fromverification device 146 during the redemption time window, and terminatesecond communications socket 132 without sending access token 124 ifvalidation code 582 is not received from verification device 146 duringthe redemption tine window.

Flowchart 260 continues with, upon receiving verification responsemessage 154 including validation code 582, sending access token 124 foraccessing user account 122 to access device 143 through secondcommunications socket 132 (action 266). Access token 124 may be sent toaccess device 143 through second communications socket 132 by softwarecode 110, executed by hardware processor 104. Subsequent o action 66,hardware processor 104 of system 100 may execute software code 110 toreceive access token 124 from access device 143 (action 267), and uponreceiving access token 124 from access device 143, may grant accessdevice 143 access to user account 122 (action 268).

It is noted that, in some implementations, hardware processor 104 mayexecute software code 110 to determine that user account 122 is in goodstanding before transmitting verification request message 152/552 inaction 264. In those implementations, if user account 122 is determinednot to be in good standing, the required call-to-action included inverification request message 152/552 may include the requirement thatuser 141 perform a password change for user account 122, usingverification device 146. For example, in those implementations, hardwareprocessor 104 of system 100 may execute software code 110 to send arequest for a password change to verification device 146 through thirdcommunications socket 133, receive a new password through thirdcommunications socket 133, update user account 122 to associate the newpassword with user account, and send access token 124 to access device143 through second communications socket 132 after user account 122 hasbeen updated with the new password.

It is further noted that, in some implementations, access token 124 maybe a one-time use access token, or may be redeemable during a redemptiontime window beginning when access token 124 is sent to access device 143in action 266, such as a fifteen minute redemption time window merely asan example. In some of those implementations, hardware processor 104 mayfurther execute software code 110 to grant access device 143 access touser account 122 if access token 124 is received from access device 143during the redemption time window, but to deny access device 143 accessto user account 122 if access token 124 is received from access device143 after expiration of the redemption time window.

Moreover, in some implementations, access token 124 may be for eventspecific or content specific use. For example, verification requestmessage 152/552 sent to user 141 in the use case shown in FIG. 1C mayread “Streaming Media Player A of secondary user 142 wants to accesscontent Z” and user 141 can choose to authorize access to content Z butnot to other content associated with user account 122. Alternatively, inanother use case, secondary user 142 may type in a promotion code (promocode) associated with the user account 122 of user 141, and user 141 canbe notified by verification request message 152/552 that the promo codeis being used before authorizing.

Although not included in the outline provided by flowchart 260, in someimplementations the present method may also include informingverification device 146 or access device 143 of a successful login in byaccess device 143. In those implementations, hardware processor 104 mayexecute software code 110 to transmit notification 158 to access device143 and/or to verification device 146, stating that access device 143has been successfully logged in to user account 122. Exemplarynotification 658 corresponding in general to notification 158 is shownin FIG. 6 .

It is noted that, in some implementations, hardware processor 104 mayexecute software code 110, to perform actions 261, 262, 263, 264, 265,266, 267, and 268 in an automated process from which human involvementmay be omitted. It is further noted that, in some implementations,hardware processor 104 may further execute software code 110 to streammedia content associated with user account 122, such as movie, TV, orgame content, for example, to access device 143 through firstcommunications socket 131.

The systems and methods for expediting user authentication disclosed inthe present application provide substantial advantages over conventionallogin schemes. For example, the present authentication solutions allow auser to sign into multiple devices more easily. Also, the presentauthentication solutions advantageously allow an account holding user toutilize a device of another user to access their own account, and to doso in a more secure fashion than through use of a password. Forinstance, passwords can be insecure in that they may be sniffed out andre-used in a replay attack, or may be viewed by the others when enteredby a user in a non-private environment. Additionally, the present userauthentication solutions allow a user to use one device to sign intoanother device in a manner that is cross-platform and that does notrequire the user to pair or otherwise synchronize the devices together.By contrast, conventional attempts to implement password-freeauthentication have required that the devices utilize the same operatingsystem or that they be connected over the same network (e.g., being onthe same WiFi network or pairing devices using Bluetooth).

In another conventional approach to user authentication, a code isdisplayed on screen and the user is asked to visit a website on aseparate device and enter the code. When the user has entered the codeon the separate device, they are asked to log in to their account usingtheir username and password. The disadvantages of this conventionalapproach are at least twofold. First, if the two devices are somewhatdistant from one another, for example located in different rooms of aresidence, the user has to either remember the code or walk back andforth between the rooms to utilize it. Second, the user is stillrequired to perform a traditional username and password login at theseparate device. By contrast, the expedited user authentication solutiondisclosed in the present application advantageously enables user accountaccess without requiring the user to remember any codes or passwords.Thus, the present novel and inventive concepts improve over theconventional state-of-the-art by effectively combining accountverification with login assistance to advantageously expedite theprocess of user authentication.

FIG. 7 shows a diagram of an exemplary system for expediting userauthentication, according to another implementation. As shown in FIG. 7, system 700 includes computing platform 702 (hereinafter “computerserver 702”) having hardware processor 704, and system memory 706implemented as a non-transitory storage device. According to the presentexemplary implementation, system memory 706 stores user database 720including user account 722 and biometric profile 726 of user 741, aswell as software code 710 for expediting authentication of user 741.

As also shown in FIG. 7 , system 700 is implemented within a useenvironment including communication network 730 providing firstcommunications socket 731, second communications socket 732, and thirdcommunications socket 733, as well as user device 746, and user 741interacting with system 700 through use of user device 746. Also shownin FIG. 7 are login request 750, verification request message 752,verification response message 754, access token 724, biometric data 756,and notification 758.

System 700 including computer server 702 having hardware processor 704and system memory 706 storing software code 710 and user database 720corresponds in general to system 100 including computer server 102having hardware processor 104 and system memory 106 storing softwarecode 110 and user database 120, in FIGS. 1A, 1B, and 1C. Consequently,system 700, computer server 702, hardware processor 704, system memory706, software code 710, and user database 720 may share any of thecharacteristics attributed to respective system 100, computer server102, hardware processor 104, system memory 106, software code 110, anduser database 120, above.

In addition, communication network 730 providing first communicationssocket 731, second communications socket 732, and third communicationssocket 733, in FIG. 7 , corresponds in general to communication network130 providing first communications socket 131, second communicationssocket 132, and third communications socket 133, in FIGS. 1A, 1B, and1C. As a result, communication network 730, first communications socket731, second communications socket 732, and third communications socket733 may share any of the characteristics attributed to respectivecommunication network 130, first communications socket 131, secondcommunications socket 132, and third communications socket 133, above.Moreover, login request 750, verification request message 752,verification response message 754, access token 724, biometric data 756,and notification 758 correspond respectively in general to login request150, verification request message 152, verification response message154, access token 124, biometric data 156, and notification 158, andshare any of the characteristics attributed to those correspondingfeatures, above.

The implementation shown in FIG. 7 differs from. those shown in FIGS.1A, 1B, and 1C in that user 741 uses single user device 746 as both anaccess device and a verification device. User device 746 may be anysuitable system that implements data processing capabilities sufficientto provide a user interface, support connections to communicationnetwork 730, and implement the functionality ascribed to user device 746herein. In various implementations, user device 746 may take the form ofa desktop computer, a laptop computer, a game console, a smart TV, astreaming media player, or a wearable communication device such as asmartwatch or AR or VR headset or glasses, to name a few examples.

User 741 may utilize user device 746 to attempt to log in to useraccount 722 on computer server 702, but may have trouble doing sobecause user 741 has forgotten his/her password, for example. User 741may utilize user device 746 to send login request 750 to computer server702 through first communications socket 731 between user device 746 andcomputer server 702, where login request 750 includes informationidentifying user device 746 and information identifying user 741 of userdevice 746, who is the user linked to user account. 722. In response toreceiving login request 750 from user device 746 through firstcommunications socket 731, computer server 702 opens secondcommunications socket 732 between user device 746 and computer server702, and upon opening second communications socket 732, generatesverification request message 752 including a required call-to-action atuser device 746, as well as a validation code.

Computer server 702 then transmits, through third communications socket733, verification request message 752 including the requiredcall-to-action and validation code to user device 746, and receives,through third communications socket 733, from user device 746 and inresponse to the required call-to-action, verification response message754 including verification that the required call-to-action has beencompleted at user device 746. For example, verification response message754 may return the validation code included in verification requestmessage 752 to system 700 for redemption. In some implementations, therequired call-to-action may include user 741 utilizing user device 746to submit biometric data 756 of user 741 to computer server 702, asdiscussed above by reference to action 265 in FIG. 2 .

Upon receiving verification response message 754 including thevalidation code, computer server 702 sends access token 724 foraccessing user account 722 to user device 746 through secondcommunications socket 732, and then receives access token 724 from userdevice 746. Upon receiving access token 724 from user device 746,computer server 702 may grant user device 746 access to user account722.

As discussed above by reference to FIG. 1A, in some implementations,computer server 702 play determine that user account 722 is in goodstanding before transmitting verification request message 752. In thoseimplementations, if user account is determined not to be in goodstanding, the required call-to-action included in verification requestmessage 752 may include the requirement that user 741 perform a passwordchange for user account 722, using user device 746.

As further discussed above, in some implementations, the validation codeincluded in verification request message 752 and returned to system 700in verification response message 753 may be redeemable during aredemption time window beginning when verification request message 752is transmitted to user device 746, such as a fifteen minute redemptiontime window merely as an example. In some of those implementations,hardware processor 704 may further execute software code 710 to sendaccess token 724 through second communications socket 732 to user device746 if the validation code is received from user device 746 during theredemption time window, and terminate second communications socket 732without sending access token 724 if the validation code is not receivedfrom user device 746 during the redemption time window.

As also discussed above, access token 724 may be a one-time use accesstoken, or may be redeemable during a redemption time window beginningwhen access token 724 is sent to user device 746, such as a fifteenminute redemption time window for example. In some of thoseimplementations, computer server 702 may grant user device 746 access touser account 722 if access token 724 is received from user device 746during the redemption time window, but may deny user device 746 accessto user account 722 if access token 724 is received from user device 746after expiration of the redemption time window.

Thus, the present application discloses systems and methods forexpediting user authentication that overcome the drawbacks anddeficiencies in the conventional art. From the above description it ismanifest that various techniques can be used for implementing theconcepts described in the present application without departing from thescope of those concepts, Moreover, while the concepts have beendescribed with specific reference to certain implementations, a personof ordinary skill in the art would recognize that changes can be made inform and detail without departing from the scope of those concepts. Assuch, the described implementations are to be considered in all respectsas illustrative and not restrictive. It should also be understood thatthe present application is not limited to the particular implementationsdescribed herein, but many rearrangements, modifications, andsubstitutions are possible without departing from the scope of thepresent disclosure.

1-20. (canceled)
 21. A system for authenticating a user the systemcomprising: a computer server including a hardware processor and amemory; a software code stored in the memory; the hardware processorconfigured to execute the software code to: receive a login request froma user device, the login request including information identifying theuser device; generate, in response to receiving the login request, averification request message including a validation code embedded in theverification request message, wherein the verification request messageenables automatic use of the validation code; transmit, in response toreceiving the login request, the verification request message includingthe validation code to a verification device, wherein the validationcode is not visible to the user of the verification device; receive, inresponse to transmitting the verification request message, from theverification device, the validation code and the information identifyingthe user device; and allow the user device to be logged in using thereceived validation code, in response to receiving the validation codefrom the verification device.
 22. The system of claim 21, wherein thehardware processor is further configured to execute the software codeto: inform the user device of a successful login, in response toallowing the user device to be logged in.
 23. The system of claim 21,wherein the verification device is the user device.
 24. The system ofclaim 21, wherein the verification device is different than the userdevice.
 25. The system of claim 21, wherein the verification device andthe user device are both in possession of the user.
 26. The system ofclaim 21, wherein the validation code is redeemable during a redemptiontime window beginning when the verification request message istransmitted to the verification device.
 27. The system of claim 21,wherein the verification request message is transmitted as one of anemail message or a Short Message Service (SMS) message.
 28. The systemof claim 27, wherein the validation code and the information identifyingthe user device are received in response to a single click on theverification request message.
 29. The system of claim 21, wherein thehardware processor is configured to further execute the software codeto: transmit a delivery prompt to the user device, wherein the deliveryprompt informs the user that the verification request message has beentransmitted to the verification device.
 30. The system of claim 21,wherein the user device is one of a streaming media player, a gameconsole, or a smart TV, and wherein the verification device is one of alaptop computer, a tablet computer, a desktop computer, a smartphone, ora wearable communication device.
 31. A method for use by a computersystem to authenticate a user, the method comprising: receiving a loginrequest from a user device, the login request including informationidentifying the user device; generating, in response to receiving thelogin request, a verification request message including a validationcode embedded in the verification request message, wherein theverification request message enables automatic use of the validationcode; transmitting, in response to receiving the login request, theverification request message including the validation code to averification device, wherein the validation code is not visible to theuser of the verification device; receiving, in response to transmittingthe verification request message, from the verification device, thevalidation code and the information identifying the user device; andallowing the user device to be logged in using the received validationcode, in response to receiving the validation code from the verificationdevice.
 32. The method of claim 31, further comprising: informing theuser device of a successful login, in response to allowing the userdevice to be logged in.
 33. The method of claim 31, wherein theverification device is the user device.
 34. The method of claim 31,wherein the verification device is different than the user device. 35The method of claim 31, wherein the verification device and the userdevice are both in possession of the user.
 36. The method of claim 31,wherein the validation code is redeemable during a redemption timewindow beginning when the verification request message is transmitted tothe verification device.
 37. The method of claim 31, wherein theverification request message is transmitted as one of an email messageor a Short Message Service (SMS) message.
 38. The method of claim 37,wherein the validation code and the information identifying the userdevice are received in response to a single click on the verificationrequest message.
 39. The method of claim 31, further comprising:transmit a delivery prompt to the user device, wherein the deliveryprompt informs the user that the verification request message has beentransmitted to the verification device.
 40. The method of claim 31,wherein the user device is one of a streaming media player, a gameconsole, or a smart TV, and wherein the verification device is one of alaptop computer, a tablet computer, a desktop computer, a smartphone, ora wearable communication device.